The present invention relates to the field of enterprise work flow management tools, and more particularly, to computer tools for designing and implementing integrated enterprise processes on computer systems using standardized screens.
Using enterprise software to accomplish a business process can be an extremely complicated undertaking today, given the plethora of different systems and complex interfaces that people must manipulate. The tremendous information technology advancements that have occurred over the past twenty-five years have changed virtually every aspect of business. Enormous business value has been generated by the investments that companies have made in enterprise resource planning (ERP) systems, databases, desktop applications, best-of-breed solutions, legacy systems, and other technologies. Unfortunately, most firms are unable to realize the full benefits of these investments because the usability of their systems has lagged behind the improvements in hardware, infrastructure, and applications. Consequently, it is crucial that these companies find ways to make their computer systems easier to use. The computer usability problem is being driven by several trends that are changing today""s business environment. More and more business functions across the enterprise are beginning to employ computer applications. At the same time the number and types of software applications used to accomplish business processes are proliferating. Also, software has continued to increase in complexity and become rich with unnecessary, extraneous features. Moreover, due to diminishing computer hardware costs, software products have been able to avoid using computer resources efficiently. Compounding the problem, the integration of systems within an enterprise has caused those systems to become more complex.
It is common to find many, if not all, of these trends working together within an organization to drive up information system complexity. This interaction adversely affects usability at multiple levels within the enterprise, due to the simultaneous contributions of software applications, business processes and functions, and system integration. A key difficulty has been the way in which information systems have been defined as merely a group of applications that automate tasks to improve the efficiency and/or accuracy of specific work activities. This application-centric view of systems is commonly referred to as the application model. This model was a much better fit with the way that people used to work within companies, rather than the broader process orientation that many companies have today.
Application functionality is a key driver of competition in the software industry, and this has caused developers to focus on the race for additional features, at the expense of software usability. However, more powerful applications do not necessarily yield more productive workers. Today""s application software provides a high degree of functionality, of which only a small fraction ever gets used. For any individual user most features will be useless. The more objects shown to a user, the longer it will take the user to find the ones they need. Even if it only takes the user half a second to check features they do not need, at the end of the year, many hours may have been wasted. Also, it may be difficult for many users in a business environment to map the correct application functions, in the correct order, to their business process objectives. Adding features that have less and less utility has made it more difficult for typical business users to find the correct features to achieve their objectives, because there is a larger set to choose from. The bottom line is that these extra features waste user time and system resources.
These usability problems are compounded when a business process requires users to use several different applications to accomplish their goal, a common situation in most organizations. In fact, it is estimated that approximately eighty percent of information workers have to learn and stay competent in at least six different software applications to do their job. Even companies that have invested heavily in ERP systems and enterprise application integration are finding this to be true, because they are unable run their entire business on just one information system.
Business users today must use very complex software applications, and plenty of them, to get their work done. The difficulty that people encounter when using enterprise software contributes to poor customer service and lost business opportunities. The costs and time required to train and provide technical support for information workers continue to rise. Even after people are trained, it is hard for companies to retain their intellectual capital due to turnover and undocumented xe2x80x9cwork aroundxe2x80x9d processes. All of these issues prevent companies from realizing the intrinsic business value that currently exists within their corporate information systems.
The information technology (IT) departments of some enterprises may attempt to solve some of the above problems by creating custom enterprise software tools for specific business processes employed in their respective enterprises. However, development of custom software is an extremely arduous task that most IT departments lack the time and/or skill to accomplish. Fourth generation programming languages and graphical programming tools, such as Visual Basic or PowerBuilder, may assist in development time and ease, however, even with such modem development tools, development time and difficulty may be prohibitive. Such modem development tools provide component-based programming which allows the developer to simply select a component or object for displaying a data field or a dialog box. Modern development tools may provide many such components from which the developer must select the appropriate one. Once the developer has selected a component, the component must still be mapped to the data which it displays. For example, a component may be used to display a field of data from a database. In addition to specifying the database entry to which the component is mapped, the developer must also specify such parameters as the length and format of the display field, the location of the component on the display, etc. Component mapping typically requires a large portion of the development time.
Also, the process developer may want to have data validation functionality associated with each component to ensure that only proper data entries are received. For example, in a component for currency data or time data, it may be desirable to ensure that data entered is in the correct currency or time format. To accomplish this, the developer may have to code specific validation logic associated with each component. Validation coding may significantly add to the overall development time.
Furthermore, numerous components are typically involved for each user interface or display used to accomplish a task or process. The data mapping and validation described above may need to be repeated for each component. Thus, component data mapping and validation coding typically consume a large portion of development time. Also, as business tasks and processes become more complicated, more and more components may be added to a user interface to accomplish the tasks or processes. Not only does this complexity lengthen development time, but the usability of the user interface typically decreases with complexity. A display or user interface containing multiple components to perform various functions and tasks simultaneously may require a lengthy learning curve for a business user, such as a warehouse worker or sales person. Also, the complexity may lead to more mistakes in using the user interface.
Another problem faced by enterprise IT departments is that once enterprise software is developed to accomplish a business process, the executable code must be distributed to each user""s computer. Not only is distribution of executables time consuming, but version problems may result. If an employee uses an old version, he may not perform his task correctly. Also, old versions may cause synchronization problems with other software such as a database which could result in crashes or data corruption. Some of these problems may be solved by performing distribution and version control over the company local area network (LAN), but if a user fails to leave his computer on and connected to the network, then the same problems may result.
FIG. 1 illustrates traditional application based computing employed by businesses today. A business user may need to accomplish a process 10, such as generating a quote. The user may employ a suite of different applications 30 to accomplish the process 10. For example, the process of generating a quote may include many activities 12-24 that are spread across several different applications 32-44. The user may first need to search private specifications from vendors whose products are resold, as indicated at 12. To accomplish this task the user may need to access one or more online vendor databases 32. Next, the user may need to check product availability, as indicated at 14. One or more inventory databases 34 may need to be accessed to check product availability. Next, a weekly price sheet may need to be checked for price reductions and to compare the product margins, as indicated at 16, by accessing an intranet HTML page 36. The user may then need to reference assembly schedules to ensure that resources are available to meet the ship date, as indicated at 18, by accessing a material production system 40. The user may then generate and modify an initial quote, as indicated at 20, by using a spreadsheet application 38 that retrieves parts and prices from the inventory database 34. The quote and related documents may then be assembled, as indicated at 22, by using a word processor application 42. Finally, the quote may be added to a quote database, as indicated at 24, by using quote data base application 44. The quote may also be sent to a customer by using an email or fax application (not shown).
This approach requires much time and attention from the user (e.g., salesperson), and also requires a considerable amount of time learning the unique activities, applications, and systems involved in the process. Time spent in learning to perform all of the disparate activities in the process and learning all the different applications, as well as time spent in unnecessary data conversion or other low-level tasks is not the most productive use of a salesperson""s time. In addition, changes to any of the associated applications will require retraining of the sales force, and may necessitate modifications in the quote generation process. If customized development is required, development effort may be needed for multiple different applications to perform the process. The total required development time may be prohibitive so that the business may be forced to use less efficient off-the-shelf solutions.
Methods and apparatus are described that more easily allow development and implementation and maintenance of processes, particularly processes for carrying out business oriented activities or processes. Embodiments may allow small businesses to develop such applications quicker, with less expense and skill. Embodiments may also enable large enterprises to more easily integrate enterprise-wide data into a centrally maintainable system, using application-specific computer processes, without imposing significant user training requirements.
According to the invention, computer processes for carrying out any of a predefined class of activities, for example business processes, are defined as a series of steps using a plurality of predefined, standardized user-interface screens. These standardized interface screens are linked together in predetermined orders to, in effect, implement on the computer any activity within the class or classes for which the standardized screens are appropriate. Any number of computer processes can, therefore, be easily developed and deployed using interfaces familiar to a user. The computer process automatically takes a user from screen-to-screen, prompting the user to review information, provide information or take appropriate action. Computer processes specific to a particular activity may be easily developed, deployed and modified using these predefined, standardized screens or user-interfaces. Thus, development and maintenance of an application-specific process may be shorter and less expensive, and it may require less programming skill. Furthermore, the need for training users on new application processes may be reduced, or possibly not even necessary. Users may develop custom user-interface screen types, or customize the generic screen interfaces, which may be reused in any number of processes.
According to one aspect of the invention, application-specific computer processes are represented using metadata, which may comprise tagged data. In particular, xe2x80x9cpresentationxe2x80x9d metadata provides data to a screen rendering process running on a user""s workstation with details on how to render one of a plurality of predefined, generic screens in a manner which is specific to a particular process. For example, the metadata might include names to go into headings of columns of information being displayed, in which case the metadata would be a tag identifying that the data associated with the tag is for the headings. The information below the headings would be supplied through a database query, which would be provided in, for example SQL, with a tag indicating that it is a query.
According to another aspect, xe2x80x9cprocessxe2x80x9d metadata may be provided to define the steps of the process for enabling navigational capabilities.
According to a further aspect, metadata may be stored in a database and communicated by a process server to a client computer, which acts as a user""s workstation. This client-server system architecture allows maintenance of the computer processes in a central location and thus, in effect, remote management of their use within a network, such as a network in a large business enterprises. Furthermore, any number of application-specific computer processes may be made available and distributed to users without detailed programs for those processes having to be stored at each user workstation. Furthermore, basic interface functions with legacy databases and back-end systems may be provided to each user workstation in a large network through the server or servers. The server(s) also may access centralized databases.
According to another aspect, standardized screens used to make up an application-specific computer process are rendered within a standard, simple screen frame, which provides basic information and controls for navigating between the screens. According to a further aspect, processes may be launched from a xe2x80x9cto doxe2x80x9d list, listing specific tasks which have been assigned to a user. Selecting a task launches a process comprising a sequence of user-interface screens with appropriate data for carrying out that task.
One embodiment involves a method for process-based computing. The method may include transmitting a request for a step of a predefined process. The request may be transmitted from a client computer to a server computer. Accessing of a process database to retrieve process data for the request may be performed by the server computer. The process data may then be transmitted from the server computer to the client computer. The client computer may render one or more screens on a display as indicated by the process data for accomplishing the step.
This method may also include the server computer accessing data from an application or data store in response to the request for a step from the client computer. The server computer may transmit this data to the client computer and the client computer may render this data in the one or more screens as indicated by the process data. The application or data store may be accessed by the server computer over a network. The server computer may call a business object for accessing the data from the application or data store. The business object provides functionality to interface the server computer to the application or data store. Business objects may be stored in a business object repository which may be included within the process database. The business objects may be reusable objects so that the same business object may be used to interface data for different steps of the predefined process to the same application or data store.
The process database may be accessed by the server computer over a network. All of the steps of the predefined process may be defined by process data stored within the process database as metadata. The process database may be an open database conductivity (ODBC) compliant relational database. The process data stored within the process database may be formatted in an extensible markup language (XML). The process data transmitted from the server computer to the client computer may comprise XML formatted data. The process data may be transmitted from the server computer to the client computer over an intranet or over the Internet.
Rendering the one or more screens for a step of the predefined process may include displaying the one or more screens as indicated by the process data within a common navigational framework. User input may be received on the client computer to complete a step. The client computer may request a next step from the server computer. This may be repeated to complete the predefined process. The process data may be supplied by the server computer one step at a time so that process data for a next step is not provided until a current step is completed on the client computer. A predefined process may be initially launched from the client computer. Upon launching a predefined process, the first step of the predefined process is requested and received from the server computer.
Navigational control data may be transmitted from the client computer to the server computer. The navigational control data may include requesting a next step of the predefined process from the server computer or requesting a previous step of the predefined process from the server computer. The navigational control data may also include data for assigning the predefined process to a different user. Control data also may include data for pausing or canceling the current step of the predefined process.
Rendering screens by the client computer as indicated by process data received from the server computer, may include displaying a target screen for manipulating a remote data store. A list screen for manipulating rows of data in a remote data store may also be displayed. Process data transmitted by the server computer to the client computer may also indicate for the client computer to display a tree screen for presenting hierarchically related data. The process data may also indicate for a spreadsheet screen to be displayed for populating or manipulating data in a spreadsheet format. The server computer may interface the spreadsheet screen on the client computer to a spreadsheet application. Similarly, a document screen may be displayed for populating or editing formatted documents, and the server computer may interface the document screen on the client computer to a document application. The client may also be instructed to display a browser screen for viewing and navigating among information resources, or a report screen for viewing an information resource. A calendar screen may also be displayed, as indicated by the process data, for manipulating data from a remote data store in a calendar format. Also, a launch pad screen may be displayed by the client computer, as indicated by process data. The launch screen may list predefined processes available to be launched from the client computer. Instructions for each of the screens may also be displayed within a framework by the client computer on how to complete each step of the predefined process associated with the screens.
The client-computer may transmit requests for steps of the predefined process to the server computer using a protocol including hypertext transport protocol (HTTP). The requests may be transmitted over an intranet or over the Internet.
The predefined process may be defined as a series of steps to accomplish an objective. Process data representing the series of steps may be stored in the process database. Defining a process may include indicating one or more standard screens to be used for each of a series of steps. The standard screens may be selected from a limited number of standard screens. A purpose may also be specified for each of the screens. A business object may also be specified for each screen. The business object may specify data to be displayed by the screen. The business object may also provide an interface to a remote data store or application. The series of screens with specified purposes and business objects may be defined in metadata, which may be formatted in XML. Storing process data representing the series of steps may include transmitting the metadata to the server computer. The server computer may insert the metadata in the process database.
A client application may be downloaded from the server computer to the client computer. Requests for steps of a predefined process and rendering of the screens to accomplish the steps, as indicated by process data received from the server computer, are performed by the client application on the client computer. The client application may include platform independent code running on a virtual machine on said client computer. The virtual machine may be within a web browser on the client computer.
A computer system may include at least on CPU and a storage medium accessible by the CPU. The storage medium may include program instructions operable to implement a client interface. The client interface may be configured to receive process data indicating a first screen to be used for accomplishing a first step of a predefined process. The client interface may also be configured to render the first screen within a navigational framework on a user display. Following user input to the navigational framework, the client interface may receive process data indicating a next screen to be used for accomplishing another step of the predefined process. The client interface may render the next screen within the navigational framework on the user display. The client interface may continue to receive process data and render the screen accordingly to complete the predefined process. The computer system may also include a communication link coupled to the CPU. The client interface may be configured to receive the process data from a process server across the communication link. Screens rendered by the client interface, and the fuctionality of those screens, may be determined by the process data received by the client interface. The process data may be stored in a process database remote from the computer system on which the client interface is implemented. Program instructions operable to implement the client interface may be downloaded to the storage medium from the process server.
Screens rendered by the client interface to accomplish the steps of the predefined process are selected from a limited number of standard screens that are specified by the process data. The process server may provide an interface between the standard screens and back-end stores or applications. The back-end data stores or applications may be remote to the client interface and/or process server.
Each standard screen may be rendered by the client interface within a common navigational framework. The navigational framework may include one or more graphical controls for a user to control the flow of the predefined process. A next control may be included to advance to a next step of the predefined process. A previous control may be included to return to a previous step. An assign control may be included to assign the predefined process at its current stage to another user. A pause control may be included to stop the predefined process and save it at its current step. A cancel control may be included to stop the predefined process without saving it at its current step. The navigational framework may include an instruction component for displaying instructions on completing the current step of the predefined process. The client interface may be configured to send results of a completed step to the process server across the communication link. The client interface may communicate with the process server using HTTP or a security enhanced HTTP such as HTTPS. The client interface may include Java instructions and may run on a Java virtual machine within a web browser.